Zane Scott, Vitech Vice President of Professional Services
In the world of model-based systems engineering there is a surprising amount of confusion over the role and concept of models. One would think that a concept important enough to be contained in the very name of the practice would have a well-settled definition. But such is not the case in MBSE. Still at issue is what it takes to be the kind of model on which systems engineering can be based.
To understand this issue, we first look at the nature of models. In a general sense, models are limited representations of an existing reality. A plastic replica of an airplane may be made to “scale,” painted like the original, and have the insignia of its origin displayed. It represents the appearance of the real plane, but it is limited. It won’t fly, it doesn’t resist the force of a hard landing, etc.
In the broadest sense, many representations may be “models.” Pictures of a reality can be thought of as a model. Systems of formulae describing the performance of the real thing can fit into this definition of a “limited representation.” Many kinds of representations are technically models within the meaning of the general definition.
All models are wrong, but some are useful
George E. P. Box, the English statistician, famously observed, “All models are wrong, but some are useful.” He further clarified that idea with this expansion, “Remember that all models are wrong; the practical question is how wrong do they have to be to not be useful.” What did he mean?
Box’s assertion first tacitly points to the definition of a model as a “limited representation.” That means a model approximates, but does not match, the reality being represented. To this extent it is “wrong” because it fails in one or more aspects to accurately depict all of the aspects of the reality. But in a “useful” model, that failure is inconsequential. The shortcomings of the depiction do not deprive the modeler of necessary insight into the reality.
As Box brings into focus, there is a point at which the representation can be limited in a way or ways that interfere with use to which the model is purposed. Beyond that point, the model is not useful. The representation lacks something essential to its purpose. So what does it take to qualify as a useful systems engineering model?
An interventional practice
For the answer to that question, we must look to the purpose of systems engineering. Systems engineering is, by its nature, an interventional practice. Like the practitioners of systems thinking or systems science, the systems engineer must understand the nature of systems. Systems engineers use the working definition of a system (“A system is a construct or collection of different elements that together produce results not obtainable by the elements alone.” – INCOSE) to structure their work. The system results are generated by the ways in which the system construct holds the different elements in relation to each other.
The key to systems understanding is understanding that the results arise from the relationships among the elements. In his book The Systems View of Life: A Unifying Vision (2014), physicist turned biologist Fritjof Capra states, “the essential properties of a . . . system . . . arise from the interactions and relationships among the parts.” But the systems engineer takes this understanding a step further.
Using the systems understanding, the systems engineer intervenes in (creates or modifies) a system solution in order to cause the “construct of different elements” to “produce results” that will solve the problem at hand. This is the central aim of the systems engineer.
In order to produce the desired results, the systems engineer leverages the definition from both ends. The engineer seeks to identify what construct(s) will produce those results and, for a given construct, predict what results will be produced.
With this two-headed purpose in mind, we can see what is required of a true “systems engineering model.” At the point that it fails to provide a sufficient basis for making these predictions, the model loses its utility. It has, in Box’s parlance, become wrong enough not to be useful for the fundamental purpose of systems engineering.
The emphasis is added because there may still be utility in models that don’t support the full core purpose of systems engineering. They may not offer insight into all the aspects of the construct of elements at a level sufficient to support the prediction of results, yet still offer useful information about the design. This would be true of a physics-based performance model designed to test the capability of a set of system components. It would be true of a drawing depicting the physical relationship of system components to one another. These are value-adding – technically “models” in a broad sense – but they do not provide enough information to be the basis for predicting whether the system will produce results that satisfy the desired purposes behind its creation.
A true model
For that, a different kind of model is needed. The model must represent all of the domains of the systems engineering practice: requirements, logical architecture, physical architecture, and validation and verification. Even more importantly, because the system results are the product of the inter-relationships of the system elements, a true systems engineering model must clearly depict the relationships. It should offer insight into the “construct or collection of different elements” in such a way that the systems engineer can accurately understand and predict the results that will be produced.
In this way, the systems engineering model is the basis for sound systems engineering. It can support the interventional practice of the systems engineer. Other models may be involved in the process, but the systems engineering model is foundational.
